[レポート] マイクロサービスはコンテナで実現する?それともサーバーレスで実現する? #reinvent #ARC214

[レポート] マイクロサービスはコンテナで実現する?それともサーバーレスで実現する? #reinvent #ARC214

Clock Icon2018.11.29

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

本記事は「Using Containers and Serverless to Deploy Microservices」のレポートです。

セッション概要

Microservices are a great way to segment your application into well-defined, self-contained units of functionality. Come join us in this chalk talk as we discuss two common architectures for deploying microservices: containers and serverless. Please join us for a speaker meet-and-greet following this session at the Speaker Lounge (ARIA East, Level 1, Willow Lounge). The meet-and-greet starts 15 minutes after the session and runs for half an hour.

レポート

ゴール

  • コンテナ、サーバレス、それぞれのアーキテクチャのメリット、トレードオフを理解する
    • AWS上でコンテナ、サーバーレスを動かす場合の選択肢を理解する
    • コンテナ、サーバレスアーキテクチャーの考慮すべきポイントを理解する
    • 一般的な使用事例とアプローチをレビューする

アジェンダ

  • AWS上でのコンテナ、サーバレスのそれぞれの選択肢
  • コンテナとサーバレス、アーキテクチャの選択
  • マイクロサービスアーキテクチャを実現するためにAWSで利用できるサービス

AWS上でのコンテナ、サーバレスのそれぞれの選択肢

マイクロサービスの選択

  • コンテナ
    • Amazon ECS
    • Amazon EKS
    • Amazon Fargate
  • サーバーレス
    • Lambda

ECS、EKS、Fargate

  • AWSでコンテナ化アプリケーションを実行するためのプラットフォーム
  • ニーズに合わせてアプリケーションを簡単に実行し拡張可能
  • 他のAWSサービスとのネイティブ統合
  • CI/CDサービスとの連携

コンテナを利用したアーキテクチャの例

  • パブリックなセグメントに配置したELBを経由してECSクラスタにアクセスする
  • ECSクラスタはオートスケーリンググループによりリソースを自動で拡張
  • 必要に応じてECSクラスタから別のサービスを実行

コンテナ実行環境の役割

  • ECS、EKS
    • コントロールプレーン
    • コンテナの管理を行う(死活監視、デプロイなど)
  • EC2、Fargate
    • データプレーン
    • コンテナが実行される環境、各状態をコントロールプレーンにフィードバック

※BlackBeltの資料になりますが、こちらがわかりやすいです。

Serverless:Lambda

  • サーバーのことを考えずにコードを実行するプラットフォーム
  • プロビジョニングまたは管理するサーバーがない
  • 使い方のスケール
  • アイドル費用は発生しない
  • 高可用性が組み込まれ、フォールトトレランスが容易
  • 他のAWSサービスとのネイティブ統合
  • イベントドリブンフレームワーク
  • 複数の呼び出しモデル

Lambdaを利用したアーキテクチャの例

  • APIGateway(ユーザーからのリクエストを受け付ける、必要なリクエストを抽出しLambdaを実行する)
  • Lambda(メインの処理を実行する、必要に応じてデータストアであるDynamoDBを利用する)
  • DynamoDB(Lambdaから呼び出されるデータストア)

それぞれのアーキテクチャに関する考察

  • コンテナ
    • 自身が用意した環境で好きなコードをビルドすることができる
    • 選択肢が多い
    • 管理とオーケストレーションが必要
    • 複数のネットワークモード、成熟したツールを利用することが可能
  • サーバーレス
    • 標準化された選択肢
    • スケーラブルなプラットフォームを駆動する
    • セキュリティとスケーリングがAWSに管理される
    • コンテナが不要
    • 必要なリソースを選択(128M to 3G)
    • ツールの開発
    • 組織の準備

アーキテクチャの選択

コンテナが適しているケース

  • 低起動待ち時間
  • 15分以上の処理実行
  • 予測可能な高いトラフィック使用量
  • 計算環境の完全な制御

サーバーレスが適しているケース

  • イベントドリブンなアクション
  • 予測不可能なトラフィックを処理する能力
  • 早くビジネス価値を提供する
  • 運用上の複雑さをAWSに任せる

決めることができない場合

両方のアーキテクチャを採用することも検討する

マイクロサービスアーキテクチャの実現に利用できるAWSのサービス

API Gateway

  • 分散システムのベストプラクティスを可能にする
    • スロットリング
    • 指数的なフォールバックで再試行
    • フェイルファースト
  • PrivateやPublicサービスのサポート

AWS AppSync

  • データ駆動のリアルタイムアプリケーションを可能にする
    • 複数のデータソース、1つのエンドポイント
    • クライアントがペイロードを指定する
    • 最新データをサブスクリプション

X Ray

  • 分散アプリケーションの洞察を提供
    • アプリケーションの問題を明らかにする
    • アプリケーションのパフォーマンスを向上させる
    • ECS、Lambdaなどに対応

To Learn more

さいごに

コンテナ、サーバレス、それぞれのアーキテクチャ特性を見極め、最適なシステムを構築していきたいですね。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.